Ja, wir kommen jetzt zum Thema Programmstruktur und Module und in diesem Kapitel möchte ich

zunächst ein paar grundlegende Überlegungen über Software Design und wie die Eigenschaften der

Programmiersprache C sich da einordnen lassen machen und anschließend dann genauer darauf

eingehen wie man diese Strukturierungsmethoden letztendlich konkret in einem C-Programm und

Modulen eines C-Programms umsetzen kann. Software Design beschäftigt sich ja letztendlich mit

grundsätzlichen Überlegungen über die Struktur eines Programms vor Beginn der Programmierung.

Also wie strukturiere ich letztendlich mein Problem so, dass ich es vernünftig mit Hilfe

von meinen Software-Strukturen abbilden kann und da haben sich in den letzten 60 Jahren inzwischen

eigentlich verschiedene Design-Methoden entwickelt. Die ersteren richtig strukturierten Methoden

beschäftigten sich mit einem Top-Down-Entwurf und prozeduraler Programmierung, imperativer Programmierung,

was eine sehr traditionelle Methode, die bis Mitte der 1980er Jahre eigentlich fast ausschließlich

eingesetzt wurde und Programmiersprachen wie Fortran, Cobol, Pascal oder C waren letztendlich

auch die Grundlagen dafür und diese Design-Methode hat sich an den Elementen und den Strukturierungsmethoden

dieser Programmiersprachen orientiert. In den 80er Jahren hat sich dann parallel dazu zunächst und

dann eigentlich als führende Methode der objektorientierten Entwurf herausgebildet und die

Motivation dafür und letztendlich das Ziel war die Bewältigung sehr komplexer Probleme. Und es gab

damals eben so Aussagen, dass die traditionelle Top-Down-Entwurfsmethode in dem Augenblick auf

ernsthafte Probleme stößt, wenn Programmcode hunderttausend Zeilen Programmcode oder mehr

umfasst. Und das war natürlich die Zeit, in der Software-Systeme so richtig groß wurden,

zum Teil ja dann Millionen Lines of Code beinhalteten und solche großen Software-Systeme

waren dann mit eben diesem Top-Down-Entwurf nur noch sehr schwer in den Griff zu bekommen und

es gab dann also auch ganz massive Defizite, die dann auch in sehr fehleranfälligen Software-Systemen

resultierten. Programmiersprachen für objektorientierten Entwurf, so eine der

ersten war Smalltalk, dann auch C++, letztendlich eine Erweiterung von C um die objektorientierten

Konzepte und dann ab Mitte der 1990er Jahre dann vor allem auch Java, C-Sharp und viele

andere Programmiersprachen, die sich dann so nach und nach entwickelt haben. Ich denke zu

den prominentesten heutzutage im Bereich der objektorientierten Programmierung gehören

mit Sicherheit jetzt C++ und Java. Wo ist jetzt so der wesentliche Unterschied? Also die zentrale

Fragestellung beim Top-Down-Entwurf ist, was habe ich zu tun? Es geht also wirklich um die Aktivitäten,

die in einem Programm ablaufen und dann ist die nächste Frage, in welche Teilaufgaben,

in welche Teilaktivitäten lässt sich diese Aufgabe untergliedern. Wenn ich also als simples

Beispiel mal sage, ich will im Rahmen der Rechnungsstellung die Rechnung für einen Kunden

ausgeben, dann sind die Teilaufgaben, dass ich die Rechnungspositionen zusammenstelle und für jede

Rechnungsposition muss ich die Lieferungsposten erstmal einlesen, ich muss vielleicht den Preis

für das Produkt ermitteln, ich muss die Mehrwertsteuer ermitteln und dann muss ich die

Rechnungspositionen addieren, die Position formatiert ausdrucken und irgendwann habe ich dann so eine

Rechnung. Und wenn man sich das anschaut, dann sind das also alles Dinge, die zu tun sind. Es geht

aber wesentlich weniger darum, was sind die Dinge, auf denen diese Operationen stattfinden. Also es

geht um Aktivitäten, aber es geht nicht um den Kunden, es geht nicht um einzelne Produkte,

die Eigenschaften haben, sondern es geht wirklich nur um Tätigkeiten. Und wenn man sich das anschaut,

wenn also die Gliederung eben nur die Aktivitäten, aber nicht die Struktur der Daten umfasst, dann

ist die Gefahr sehr groß, dass ich am Ende viele Funktionen habe, die mehr oder weniger wild auf

einer großen Menge, möglicherweise schlecht strukturierter Daten arbeiten. Und das beschreibt

jetzt im Endeffekt dieses Bildchen vielleicht etwas arg krass, aber ich habe also Funktionen und ich

habe eine Wolke von Daten, die mögen da schon strukturiert sein, aber ich habe keinen direkten

Bezug von einer Menge strukturierter Daten zu einer Funktion oder einigen wenigen Funktionen,

die da darauf arbeiten. Und es ist durchaus schon so, dass Software häufig dann, vor allem wenn sie

dann über lange Zeit, vielleicht auch über Jahrzehnte wächst, irgendwie dann so ausschaut,

wie dieses Bildchen das suggeriert. Um von dieser Unordnung letztendlich wegzukommen, wäre eine

Lösung natürlich, dass man die Datenbestände gliedert, zusammen mit den Funktionen, die